In both embedded and non-embedded CPUs, there are predominant instruction Set Architectures (ISAs) for which large bodies of software exist that could be “accelerated” for performance, or “translated” to a myriad of capable processors that could present better cost/performance benefits, provided that they could transparently access the relevant software. One also finds dominant CPU architectures that are locked in time to their ISA, and cannot evolve in performance or market reach. Such CPUs would benefit from a software-oriented processor co-architecture.
Program code conversion methods and apparatus to facilitate such acceleration, translation and co-architecture capabilities are disclosed, for example, in published PCT application WO00/22521, and others.
A problem arises in that performing program code conversion inevitably brings overheads in the conversion process, compared with native execution of the subject program on a subject processor. A particular problem arises in relation to the handling of exceptions.
An exception is a condition that changes the normal flow of control in a program. An exception indicates that a condition has occurred somewhere within the system that requires the attention of the processor and usually needs to be handled before processing can continue. Exceptions can be subdivided into various different types such as interrupts, faults, traps or aborts. The terminology varies between different architectures, and particular types or categories of exceptions may be unique to particular architectures.
An exception may be generated (“raised”) by hardware or by software. Hardware exceptions include such signals as resets, interrupts, or signals from a memory management unit. As examples, exceptions may be generated by an arithmetic logic unit or floating-point unit for numerical errors such as divide-by-zero, for overflow or underflow, or for instruction decoding errors such as privileged, reserved, trap or undefined instructions.
Software exceptions are varied respectively across various software programs and could be applied to any kind of error checking which alters the normal behaviour of the program. As an illustrative example, an instruction in the subject code causes an exception to be reported if the value of one register is greater than the value of a second register.
An exception handler is special code which is called upon when an exception occurs during the execution of a program. If the subject program does not provide a handler for a given exception, a default system exception handler will be called, usually resulting in abortion of the program being run and an error indication being returned.
Exception signals are a common mechanism for raising exceptions on many operating systems. The POSIX standard, which is adhered to by many operating systems, particularly Unix-like systems, specifies how this mechanism should behave so that exception signals are broadly similar across many systems. The most common events that trigger exceptions are when a process implemented by a program tries to (i) access an unmapped memory region or (ii) manipulate a memory region for which it does not have the correct permissions. Other common events that trigger exception signals are (iii) the receipt of a signal sent from another process, (iv) the execution by a process of an instruction that the process does not have the privilege level to execute, or (v) an I/O event in the hardware.
The present invention is particularly concerned with the precise handling of exceptions, also often referred to as precise exceptions. A precise exception is reported on a boundary between subject code instructions. When a precise exception is reported, the effects of all previous subject instructions are complete, the exception points to the first instruction of the subject code which has not been executed, and no effects from that subject instruction or any subsequent instruction have yet taken place.
In the context of binary translation, it is apparent that when a target instruction is performed on a target processor and causes an exception to be reported, the target instruction generally will not fulfil the conditions for reporting a precise exception to an exception handler written in subject code. Instructions are almost always performed on the target processor in a different order to the order of instructions in the corresponding block of subject code, firstly due to the differences between the instruction set of the subject processor for which the subject code was written and the target processor on which the target code is run, and secondly because of the optimisations that typically occur during program code conversion.
One known approach is the use of “recovery points”, which return a virtual subject machine to the conditions that applied at entry into a section of code being translated or executed, i.e. by returning the virtual subject machine to the condition prevailing at the point of entry into the current block of subject code instructions being translated or executed.
U.S. Pat. No. 5,832,205 (Kelly et al) discloses an emulator which uses a set of “working” registers which are then copied to a set of “official” virtual subject registers at the end of each section of subject code, using a gated store buffer. If an exception occurs, this will affect only the working registers and the condition of the virtual subject machine can be recovered from the “official” registers at the point of entry into that section of subject code. However, the use of “working” and “official” registers adds significantly to the overhead of the emulation process in the target processor.
As another example, WO00/65440 discloses alternating between A and B register sets to provide historical recovery points during program code conversion.
Another approach is discussed in detail in co-pending published application GB2403563 and co-pending application U.S. Ser. No. 10/726,857. Here, a variable precision exception handling is applied, by recording different levels of detail for each of a plurality of types of instructions in the subject program. That is, the quantity and type of information to be recorded is varied according to the nature of the subject instruction. Suitably, each subject instruction is determined to be one of four types, and a corresponding level of detail is recorded. A first level records no state at all. A second level provides imprecise (inaccurate) state information using a last known stack frame. A third level records a precise subject program counter in a temporary abstract register during translation, which is then retrieved to handle an exception. A fourth level generates and plants additional target code to rectify a precise state (i.e. record the subject program counter and rectify any lazy or pending subject register values) immediately preceding an exception-raising target instruction (particularly a trap-type instruction which triggers an exception).
These prior art approaches rely on recording information which allows a subject processor state to be accurately determined at the point when an exception occurs, by rolling back to a previously defined recovery point or by rectifying subject state in advance of that point. However, in the prior art, obtaining a precise state for precise exception handling is still restrictive on the program code conversion process and involves considerable overhead and/or specific hardware support.
An aim of the present invention is to improve performance when undertaking program code conversion.
A preferred aim of the present invention is to reduce overhead associated with handling of exceptions during program code conversion, and most particularly during dynamic binary translation.
Another preferred aim of the embodiments of the present invention is to reduce overhead associated with providing a precise subject-state for precise handling of exceptions.
According to the present invention there is provided an apparatus and method as set forth in the appended claims. Preferred features of the invention will be apparent from the dependent claims, and the description which follows.